setupEntitiesFTS now installs AFTER INSERT / UPDATE / DELETE triggers
on every source table that contributes rows to entities_fts (projects,
vendors, appliances, maintenance_items, incidents,
service_log_entries, quotes). Parent tables whose text is embedded in
a child's entity_name (project.title and vendor.name in quote,
maintenance_item.name in SLE) get companion _au_cascade triggers that
rebuild the child's FTS row when the parent is updated.

Cascade JOINs filter on parent.deleted_at IS NULL so a parent
soft-delete degrades the child's entity_name (project title
disappears from the quote; vendor name disappears; SLE name blanks
out) instead of leaving stale text in the index. The populate path
carries the same filter so initial rebuilds on app open match the
trigger invariant.

Trigger installation is idempotent (DROP IF EXISTS + CREATE), so
schema drift across app versions heals on the next Store.Open. FK
constraints (RESTRICT on quote parents, CASCADE on SLE parents)
continue to govern hard-delete feasibility; parent _ad triggers are
plain single-table cleanups, no cascade blocks needed.

Tests cover: insert, rename, soft-delete, parent-rename cascade for
all three relationships, parent-soft-delete cascade via raw DML (the
app gates soft-delete with live children, so the cascade path is
exercised by sync in production; raw DML matches that scenario in
tests), FK cascade on maintenance_item hard-delete, and initial
rebuild preserving the soft-delete filter for both SLE and quote
joins.

Refs micasa-dev#707.